A currently developed Policy and Charging Control (hereinafter PCC) architecture permits to integrate both policy and charging control, whilst optimizing the information flow.
The development of PCC standards is growing with different versions and, in particular, the invention is appreciably suitable for a PCC architecture in accordance with TS 23.203 (V.8.1.1) for Evolved 3GPP Packet Switched domain (wherein 3GPP stands for “3rd Generation Partnership Project”), including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses.
Generally speaking, the PCC architecture comprises an Application Function (hereinafter AF), a Policing and Charging Rules Function (hereinafter PCRF), a Policing and Charging Enforcement Function (hereinafter PCEF) and a Subscription Profile Repository (hereinafter SPR), as illustrated in FIG. 1.
In accordance with PCC standards, an AF is as an element offering applications the control of IP bearer resources according to what has been negotiated in the signalling layer; the AF communicates with the PCRF to transfer dynamic session information, namely description of the media to be delivered in the transport layer. The PCRF is the function providing policy and charging control for media components negotiated from a user equipment (hereinafter UE) of a user through the AF; the PCRF creates PCC rules based on the information received from the AF and to be installed in the PCEF. The PCEF encompasses service data flow detection based on filters included in the PCC rules, as well as online and offline charging interactions and policy enforcement. The SPR provides subscription information regarding quality of service (hereinafter QoS) parameters subscribed by the user such as bandwidth and others.
A current PCC behaviour is exemplary illustrated in FIG. 2 wherein a UE accesses a streaming server. In this exemplary PCC architecture, the UE connects to a streaming server and negotiates the session. During the session negotiation the IP ports used by the end points, the type of media (audio, video, etc.) and the QoS parameters are defined. Then, the streaming server provides the session information that has been negotiated to the PCRF. The PCRF checks that the session information received is in accordance with the operator defined policies, stores the service information and responds with acknowledgement to the application server. Subsequently, the PCRF sends a so-called RAR message to request that a gateway (hereinafter GW), which includes a PCEF, installs, modifies or removes PCC rules. Once a proper action has been taken with the PCC rules, the GW sends an RAA to acknowledge the previous RAR, initiates a procedure to create or update a so-called PDP context request message, and sends back to the PCRF required notifications with a so-called CCR message. Eventually, the PCRF stores the information received in said notifications and acknowledges the CCR back with a so-called CCA message.
At present, an IP-Connectivity Access Network (hereinafter IP-CAN) session is the association between a UE and an IP network. This association is identified by a UE IP address together with UE identity information, if available. An IP-CAN session incorporates one or more IP-CAN bearers. Support for multiple IP-CAN bearers per IP-CAN session is IP-CAN specific. An IP-CAN session exists as long as the UE IP address is established and announced to the IP network. For the sake of simplicity, IP-CAN session may be also referred to as ‘user session’ throughout this invention disclosure.
In a conventional PCC architecture, the PCRF thus receives information of each particular user session, and takes actions over each particular user session.
However, in some situations, a policy control at individual user level is not enough. For example, a control of the aggregated load generated by a plurality of users in a certain location area may be essential in order to avoid network congestion. In principle, this plurality of users cannot be pre-defined since it is not known beforehand what users will be responsible for such network congestion.
In situations like this, or where the plurality of users has surpassed a load limit in a certain location area, which could imply a risk of network congestion, an apparently suitable solution may be the downgrading of the quality of service for every user, or for a subset of users, in the plurality of users. However, this is not a suitable solution fitting user expectations.
Nowadays, where a decision has to be taken at the PCC architecture affecting a plurality of users, a plurality of corresponding orders has to be sent for each user affected, thus resulting in a higher signalling and processing load.